Determining computing-related resources to use based on client-specified constraints

ABSTRACT

Techniques are described for facilitating a client&#39;s control over use of computing-related resources on the client&#39;s behalf. In some situations, a client&#39;s control is based on specifying a group of one or more resource usage constraints with a client resource constraint manager service, which provides information about the client-specified constraints to one or more other remote network services with which the client interacts. Those remote services then use that constraint information to determine whether and how to use computing-related resources on the client&#39;s behalf. For example, the resource usage constraints specified by a client may relate to one or more particular geographical areas and/or to one or more measures of relative proximity between computing-related resources (e.g., between multiple instances of a single type of computing-related resource provided by a single service, or between multiple distinct types of computing-related resources provided by multiple unaffiliated services).

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of provisional U.S. PatentApplication No. 60/985,567, filed Nov. 5, 2007 and entitled “DeterminingComputing-Related Resources To Use Based On Client-SpecifiedConstraints,” which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The following disclosure relates generally to facilitating clientcontrol over use of computing-related resources based at least in parton constraints specified by the client.

BACKGROUND

As the use of the Internet and the World Wide Web (“Web”) has becomewidespread, it is increasingly common for users to access and usevarious types of capabilities provided by remote computing systems overthe Web, including to search for, shop for and order items (such asproducts, services and/or information) that are for purchase, rent,lease, license, trade, evaluation, sampling, subscription to, etc. Inaddition to such user-initiated interactions, software programs onremote computing systems may also interact for various purposes and invarious ways. For example, there is growing use of the Web to provideso-called “Web services,” which typically involve the programmaticinteraction of remote applications to exchange information via definedAPIs (“application program interfaces”). Web services allowheterogeneous applications and computers to interact, and may be definedand implemented using a variety of underlying protocols and techniques.For example, some Web service implementations return data in XML(“eXtensible Markup Language”) format using HTTP (“HyperText TransportProtocol”) in response to a Web service invocation request specified asa URI (“Uniform Resource Identifier”), such as a URL (“Uniform ResourceLocator”) that includes a specified operation and one or more queryparameters. Such URI-based invocation requests may, for example, bebased on the use of XML over HTTP (e.g., as part of the REpresentationalState Transfer, or “REST”, distributed interaction model that focuses onresources). In other implementations, additional underlying protocolsare used for various purposes, such as SOAP (“Simple Object AccessProtocol”) for standard message exchange, WSDL (“Web ServicesDescription Language”) for description of service invocations, and UDDI(“Universal Description, Discovery, and Integration service”) fordiscovery of available services.

While capabilities provided by services over networks to remote usersand other clients have various benefits, various problems also exist.For example, as the scale of such offerings increases (e.g., to supportlarge numbers of clients), large numbers of computing devices may becomeavailable throughout the world to store data related to the clientsand/or to handle requests from and other interactions with the clients.However, among other potential issues, it can be difficult to manage thestorage of data and to coordinate the various computing devices in suchsituations in order to provide desired behavior.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a network diagram illustrating an example embodiment in whichclients, services, and computing-related resources interact via anetwork.

FIGS. 2A-2D illustrate examples of interactions regarding use of clientresource usage constraints to control use of computing-related resourcesby network services on behalf of clients.

FIG. 3 is a block diagram illustrating an example computing systemsuitable for executing an embodiment of a software system forfacilitating use of computing-related resources on behalf of clients.

FIG. 4 illustrates a flow diagram of an example embodiment of a ClientResource Constraint Manager routine.

FIGS. 5A and 5B illustrate a flow diagram of an example embodiment of aResource Provider Service routine.

DETAILED DESCRIPTION

Techniques are described for, among other things, facilitating aclient's control over use of computing-related resources on the client'sbehalf. In at least some embodiments, a client's control of the use ofcomputing-related resources is based at least in part on one or moreconstraints specified by the client, such as based on interactions bythe client with an embodiment of a Client Resource Constraint ManagerService that provides capabilities related to the specification and useof client-specified constraints. After a client has specified one ormore such resource usage constraints, other services with which theclient interacts (e.g., remote services over a network) may obtaininformation about the specified constraints from the Client ResourceConstraint Manager Service, and then use that constraint information todetermine whether and how to use computing-related resources on behalfof the client. For example, in at least some embodiments, the resourceusage constraints specified by a client may relate to one or moreparticular geographical areas and/or to one or more measures of relativeproximity between computing-related resources (e.g., between multipleinstances of a single type of computing-related resource provided by asingle service, or between multiple distinct types of computing-relatedresources provided by multiple unaffiliated services), such thatparticular services may determine a particular geographical location atwhich to use computing-related resources on the client's behalf inaccordance with those client-specified constraints. In at least someembodiments, at least some of the described techniques are automaticallyperformed by an embodiment of the Client Resource Constraint ManagerService, as described in greater detail below.

In at least some embodiments, various Web services or other networkservices may each provide one or more types of functionality to remoteclients over one or more networks, and as part of providing thatfunctionality may each use one or more types of computing-relatedresources on behalf of their clients. Such network services maygenerally be referred to as “resource provider network services” or“resource provider services” in at least some embodiments, as discussedbelow, such as to reflect that such a service may provide a client withaccess to use one or more computing-related resources and/or with accessto results from or other benefits from using one or morecomputing-related resources on the client's behalf.

The described techniques may facilitate client control over the use ofvarious types of computing-related resources in various embodiments. Anon-exclusive list of examples of types of computing-related resourcesthat may be used on clients' behalf by resource provider servicesinclude the following: persistent data storage capabilities (e.g., onnon-volatile memory devices, such as hard disk drives); temporary datastorage capabilities (e.g., on volatile memory, such as RAM); programexecution capabilities (e.g., for a software program provided by aclient, such as a client-specific virtual machine image to be executedon one of multiple virtual machines supported by one or more physicalcomputing systems; for a software program made available by a resourceprovider service to a client for use by the client; for a softwareprogram used by a resource provider service on behalf of a client, suchas to manipulate the client's data; etc.); message queuing and/orpassing capabilities; other types of communication capabilities (e.g.,network sockets, virtual communication circuits, etc.); databasemanagement capabilities; dedicated bandwidth or other network-relatedresources; input device capabilities; output device capabilities; etc.In addition, at least some such resource provider services may each haveaccess to multiple alternative instances of a particular type ofcomputing-related resource that the service may use on behalf ofclients, such as for a particular resource provider service to providestorage-related capabilities using multiple computing systems atmultiple distinct geographical locations (e.g., using multiple datacenters in different countries or other geographical areas, with one ormore of the numerous computing systems in each data center beingavailable to provide storage for the resource provider service).

As one illustrative example, a particular storage-related resourceprovider service may provide functionality to remote clients to act as anetwork storage device, such as to allow online backup of the client'slocally stored data and/or to provide storage for large collections ofdata (e.g., photos, video, music, etc.). In such a situation, thestorage-related resource provider service may provide and use a selectedamount of storage space as a computing-related resource for each client,such as via portions of the hard disk drives of one or more computingsystems in one or more geographical locations, or alternatively on othertypes of storage mediums (e.g., magnetic tape, optical disk or tape,flash memory, etc.) and/or devices and configurations (e.g., as part ofa network storage device, storage area network, distributed database,etc.). In addition, at least some resource provider services thatprovide functionality to remote clients may provide capabilities inaddition to the use of underlying computing-related resources, such asto analyze or manipulate stored data in particular ways. For example, tocontinue the prior illustrative example, a distinct second resourceprovider service may provide functionality to remote clients to enableimage editing and other manipulation capabilities, and in so doing mayprovide and use a selected amount of storage space as acomputing-related resource for each client (e.g., temporarily whileperforming the editing and manipulation operations). The second resourceprovider service may, for example, access client images that arepermanently stored by the client on a client's local computing device,or in some embodiments may interact with the first storage-relatedresource provider service (e.g., as directed and authorized by theclient) to retrieve and use images of the client that are stored by thefirst storage-related resource provider service, even if the secondresource provider service is unaffiliated with the first storage-relatedresource provider service. Additional details related tocomputing-related resources and their use are included below.

Clients may specify and use a variety of types of computing-relatedresource usage constraints in various embodiments, and such constraintsmay take a variety of forms. For example, in at least some embodiments,at least some of the constraints may specify or otherwise relate to oneor more particular geographical locations or geographical areas, suchthat use of computing-related resources by one or more resource providerservices in accordance with those constraints are restricted to occur(or to not occur) in those particular geographical locations or areas. Ageographical location may indicate, for example, a city, a neighborhood,the location of a particular data center with multiple computingsystems, the location of a particular computing system, a particularaddress, etc. A geographical area may, for example, include multiplegeographical locations, such as by indicating a country, a state, aregion that includes multiple affiliated countries and/or states (e.g.,the European Union, the Pacific Northwest area of the United States,etc.), an area covered by a zip code, an area covered by a telephonearea code, an area bounded by specified GPS coordinates or otherlocation identifications, an area under the authority of a particularlegal entity such as a taxing authority or legislative body that mayenact one or more laws covering the area (e.g., privacy-related laws,government-specified restrictions on use of data, etc.) or othergovernmental authority, etc.

In addition, in at least some embodiments, at least some of theconstraints may specify or otherwise relate to a particular relativelocation description (e.g., that reflects a particular type or degree ofproximity to one or more indicated entities of interest), such that useof computing-related resources by one or more resource provider servicesin accordance with those constraints are restricted to occur (or to notoccur) at a location or within a geographical area that satisfies therelative location description. For example, a group of one or moreconstraints related to one or more relative locations may be specifiedand used by resource provider services such that all computing-relatedresources that are used in accordance with the group of constraints arewithin a specified distance or other proximity from each other (and, ifan entity of interest other than those resources is specified, within aspecified distance or other proximity from that entity of interest),even if the various computing-related resources are provided and/or usedby multiple unaffiliated resource provider services. A proximity orother relative location may be specified in various ways in variousembodiments, including the following: a location specified to be withina defined geographical distance from a point of interest (e.g., aparticular computing-related resource of interest); a definedproximity-related geographical distance or other size of a geographicalarea in which all corresponding computing-related resources are to belocated; a proximity that is based or measured in a manner other than ongeographical distance, such as to reflect a specified maximum degree oflatency for network communications between the relative location(s)and/or the indicated entity of interest, a specified minimum amount ofbandwidth between the relative location(s) and/or the indicated entityof interest, a specified amount of fault tolerance between the relativelocation(s) and/or the indicated entity of interest, etc.

In addition, in at least some embodiments, various resource usageconstraints may be specified and used that are not related togeographical locations or relative locations. As previously noted, insome embodiments, constraints related to fault tolerance may bespecified to facilitate client control over the use of computing-relatedresources. In some embodiments, such constraints may be specified basedon one or more degrees of proximity, such as based on an indication of arelative degree of distance between particular locations,computing-related resources, etc. For example, using such constraintsmay allow clients to use multiple redundant or otherwise alternativecomputing-related resources in various manners, and a particular degreeof fault tolerance may be desired so that all of the alternativecomputing-related resources do not fail for the same reason or based onthe same event. As one specific example, constraints related to faulttolerance may be based on a level of risk for a disaster occurring in aparticular area and/or location (e.g., earthquake zones, flood zones,wildfire zones, tornado zones, hurricane zones, etc.), such as to allowclients to control the use of computing-related resources on the basisof such risks (e.g., so that all of multiple alternativecomputing-related resources are not used within the same risk area). Inaddition, in some embodiments, such constraints related to faulttolerance may be based at least in part on computing systems thatprovide the computing-related resources, such as to ensure a sufficientdiversity in types of hardware (e.g., based on the hardware'smanufacturer, version, configuration, etc.) and/or software (e.g., suchas a particular operating system, version, etc.). Thus, for example,constraints related to fault tolerance may indicate that particularhardware and/or software should or should not be used in particularcircumstances.

A non-exclusive list of examples of types of computing-related resourceusage constraints that may be specified by a client include thefollowing: a constraint related to one or more desired geographicallocations of one or more computing-related resources (e.g., a particulargeographical location; a particular geographical area covering one ormore geographical locations; etc.); a constraint related to one or morerelative locations, such as may be based on proximity to anotherindicated entity of interest; a constraint related to a price of use ofa resource; a constraint related to a time of use of a resource; aconstraint related to a type of computing-related resource that may beused or not used; a constraint related to characteristics and/orcapabilities of a particular computing system or other computing-relatedresource (e.g., related to memory, processor, disk space, etc.); aconstraint related to a purpose of and/or type of use of acomputing-related resource; etc. In addition, at least some constraintsmay be conditional based on current conditions at a time of the use ofthe constraint, such as to only apply at indicated times or when used inindicated locations. Additional details related to client-specifiedconstraints and their use are included below.

As previously noted, in at least some embodiments, an end-user clientmay interact with a remote embodiment of a Client Resource ConstraintManager Service (also referred to in some embodiments as a “constraintmanager service” or “constraint manager network service”) in order tospecify a group of one or more computing-related resource usageconstraints, such as in an interactive manner. After the group of one ormore such constraints have been defined by a client, the client mayinteract with one or more other remote resource provider services, suchas via one or more client applications that execute on a local computingdevice of the end-user client and access functionality of the remoteresource provider services via APIs of the remote resource providerservices. The other remote resource provider services may, for example,be unaffiliated with the Client Resource Constraint Manager Service, butmay each be directed by the client to obtain information about thespecified constraints from the Client Resource Constraint ManagerService, as discussed in greater detail below. After the other remoteresource provider services obtain information about the specifiedconstraints, each of the resource provider services may then use thatinformation to determine whether and how to use computing-relatedresources on behalf of the client. In other embodiments, a resourceprovider service may obtain information about the constraints of aclient's constraint group in manners other than retrieving thatinformation from an embodiment of the Client Resource Constraint ManagerService, such as if the client provides the constraint information tothe resource provider service and/or if the constraint information isprovided to the resource provider service by another entity (e.g., bythe Client Resource Constraint Manager Service, by another resourceprovider service, etc.).

In some embodiments, a group of one or more resource usage constraintsfor a client may be mapped to one or more particular target geographicallocations that satisfy the constraints of the group, such as to selectone of multiple possible geographical locations that each satisfy theconstraints of the group to be the mapped location. When such a mappingto one or more associated target geographical locations exists for aclient's constraint group, some or all of the resource provider servicesthat operate on the client's behalf in accordance with that constraintgroup will then use computing-related resources on the client's behalfin those mapped target geographical locations. In addition, if multiplepossible geographical locations are available that each satisfy aclient's constraint group, one of the possible geographical locationsmay be selected so as to not only satisfy the client's constraint group,but to further satisfy one or more objectives for one or more resourceprovider services that use computing-related resources on the client'sbehalf in accordance with the constraint group. For example, aparticular geographical location may be selected from multiple possiblegeographical locations that satisfy a client's constraint group, and/ora particular computing system may be selected from multiple possiblecomputing systems that satisfy a client's constraint group, in such amanner as to enhance one or more operating characteristics of thecomputing-related resources that are used (e.g., to distribute a loadamong computing-related resources by increasing use of under-utilizedcomputing-related resources at the selected geographical location and/orfrom a selected computing system, by decreasing use of over-utilizedcomputing-related resources at a non-selected geographical locationand/or from a non-selected computing system, etc.). In addition, ageographical location may be selected from multiple possible locationbased on use of computing-related resources at the selected geographicallocation having lower costs, improved performance, and/or otherbenefits. Similarly, a computing system may be selected from multiplepossible computing systems based on use of computing-related resourcesprovided by the selected computing system having lower costs, improvedperformance, and/or other benefits. Furthermore, in at least someembodiments, a client may be unaware of the one or more particulartarget geographical locations and/or particular computing systems towhich the client's constraint group is matched, such as to enable amapped target geographical location or mapped target computing systemfor a client's constraint group to be changed without impacting theclient.

As discussed in greater detail below, the determination of which targetgeographical location to map to a particular group of constraints for aclient may be performed in various ways in various embodiments,including by the client resource constraint manager service, by a singleone of the resource provider services that use the constraint group(e.g., by the first resource provider service that uses the constraintgroup, by the most recent resource provider service that uses theconstraint group, etc.), by multiple or all of the resource providerservices that use the constraint group (e.g., based on negotiation orother agreement by those resource provider services), etc. For example,in at least some embodiments, a particular resource provider service mayhave access to computing-related resources at multiple geographicallocations that each satisfy a constraint group of the client, and may beallowed to initially select one of those geographical locations (e.g., aparticular data center at that initial geographical location) to whichthe constraint group will be mapped, such that the resource providerservice will initially use one or more computing-related resources onthe client's behalf at the initial geographical location. At a latertime, the resource provider service may determine that it is preferableto switch the use of computing-related resources for the client from theinitial location to another of the available geographical locations thatalso satisfies the constraint group (e.g., to another data center in adifferent second location, such as due to the initial data centerbecoming over-utilized), whether for continuing use of the sameresources (e.g., to move a particular set of stored data that is beingmaintained for the client from storage at the first location to storageat the second location) and/or for new use of related resources (e.g.,to store any new data that is provided by the client at the secondlocation). The ability of a resource provider service to initiallyselect and/or change the mapped target geographical location for aconstraint group may be restricted or controlled in various ways in atleast some embodiments, such as by the Client Resource ConstraintManager Service and/or based on how or whether the change may affectother resource provider services, as discussed in greater detail below.

As previously noted, in at least some embodiments, various resourceprovider services may each provide one or more types of functionality toclients (e.g., to remote clients over one or more networks), and as partof providing that functionality may each use one or more types ofcomputing-related resources on behalf of their clients. FIG. 1 is anetwork diagram that illustrates an example embodiment in which clients,resource provider services, and computing-related resources areinteracting over one or more networks, with a number of clientsinteracting with an illustrated embodiment of a Client ResourceConstraint Manager Service to control use of computing-related resourcesby remote resource provider services on the clients' behalf. Inparticular, the illustrated example includes a number of example clients105 a-105 c that may each be interacting with one or more exampleresource provider services 120 a-120 c and with an example embodiment ofa Client Resource Constraint Manager Service 110 over a network 100. Thenetwork 100 may, for example, be a publicly accessible network of linkednetworks, possibly operated by various distinct parties, such as theInternet. In other embodiments, the network 100 may be a privatenetwork, such as, for example, a corporate or university network that iswholly or partially inaccessible to non-privileged users. In still otherembodiments, the network 100 may include one or more private networkswith access to and/or from the Internet.

In some embodiments, clients 105 a-105 c may each include one or moreapplications that execute on a computing device of an end-user andinteract with remote resource provider services on behalf of theend-user, such as via APIs provided by the resource provider services.For example, client Z 105 a may include one or more applicationsaccessing remote resource provider services on behalf of an end-user Z(not shown). Similarly, client Y 105 b and client T 105 c may eachinclude one or more applications accessing remote resource providerservices on behalf of an end-user Y (not shown) and an end-user T (notshown), respectively. A client application used by an end-user clientmay include, for example, software that is specific to one or moreparticular resource provider services and that is provided by thoseresource provider services for use by clients interacting with theresource provider services, or may instead include software that is notspecific to particular resource provider services and may be used tointeract with various remote resource provider services (e.g., based onan end-user using a Web browser application).

The example resource provider services 120 include several resourceprovider services available for use by the clients 105, and the resourceprovider services may each provide functionality that includes use ofone or more computing-related resources. In particular, in theillustrated embodiment, each of the resource provider services may haveaccess to one or more computing-related resources of one or more typesat one or more geographical locations, referred to generally as“resource usage locations” with respect to FIG. 1. In particular, FIG. 1illustrates various resource usage locations 130 (e.g., to eachcorrespond to a distinct geographical location), which are accessible tothe resource provider services 120 and the clients 105 via the network100. For example, resource usage locations 130 a, 130 b, and 130 c mayrepresent one or more computing-related resources located in the WesternUnited States, Eastern United States, and Europe, respectively, and eachinclude at least one computing-related resource that is available foruse by at least one of the resource provider services 120. As oneexample, one of the resource usage locations 130 may represent a datacenter with multiple physical computing systems, another of the resourceusage locations 130 may represent multiple nearby data centers (e.g.,that are inter-connected with one or more dedicated high-speed datalinks or connections), and another of the resource usage locations 130may represent a single physical computing system.

The illustrated embodiment of the Client Resource Constraint ManagerService 110 in FIG. 1 performs at least some of the described techniquesin order to facilitate control by clients 105 over use ofcomputing-related resources located at resource usage locations 130 byresource provider services 120. For example, as described in greaterdetail with respect to FIGS. 2A-2D, one of the clients 105 may interactwith the Client Resource Constraint Manager Service 110 in order tospecify a group of one or more resource usage constraints. When thatclient later interacts with one or more of the resource providerservices 120, the client may instruct or otherwise request that each ofthe resource provider services 120 use computing-related resources onbehalf of the client in accordance with the specified constraint groupof the client. For example, in some embodiments, the client's specifiedconstraint group may be mapped to one or more of the resource locations130, and if so each of the resource provider services may perform theiruse of resources on the client's behalf at one of those mapped resourcelocations 130 and otherwise in accordance with the constraints of theconstraint group. In this manner, a particular client may be able to,for example, ensure that resource usage performed for the client occursin a particular specified geographical area (e.g., at one or moreresource locations 130 within that geographical area), and thatcomputing-related resources of multiple types from multiple resourceprovider services are used with a specified degree of proximity of eachother. In some embodiments, the Client Resource Constraint ManagerService 110 may be provided by a single entity (e.g., a commercialorganization) that also provides one or more of the remote resourceprovider services 120, while in other embodiments, some or all of theremote resource provider services 120 may be unaffiliated with eachother and/or with the Client Resource Constraint Manager Service 110.

For illustrative purposes, some embodiments are described below in whichspecific types of clients, network services, computing-related resourcesand resource usage constraints are used in specific manners. Theseexamples are provided for illustrative purposes and are simplified forthe sake of brevity, and it will be appreciated that the inventivetechniques may be used in a wide variety of other situations, some ofwhich are described below.

FIGS. 2A-2D illustrate examples of how the example entities illustratedin FIG. 1 may participate in various interactions regarding use ofresource usage constraints to control use of computing-related resourcesby network services on behalf of clients. In particular, FIG. 2A depictsclient Z 105 a interacting with the Client Resource Constraint ManagerService 110 and with resource provider service A 120 a. For purposes ofthis example, the resource usage locations 130 a, 130 b, and 130 c eachprovide one or more types of computing-related resources for use byresource provider services operating on behalf of clients, andcorrespond to data centers geographically located in Seattle, Wash.(Western United States); Philadelphia, Pa. (Eastern United States); andParis, France (Europe), respectively.

In this example, client Z first initiates one or more interactions 105 a1 with the Client Resource Constraint Manager Service to specify a groupof one or more resource usage constraints. In interaction 105 a 2, theClient Resource Constraint Manager Service provides client Z with areference associated with the group of constraints, for use in futureinteractions with the Client Resource Constraint Manager Service toidentify the specified constraint group. While not illustrated here, theclient Z may further specify one or more other groups of one or moreother resource usage constraints in other situations, such as to usedifferent constraint groups to control use of differentcomputing-related resources by one or more resource provider services(e.g., with one or more inter-group constraints specified that controlrelative use of two or more constraint groups, such as to indicate athat the constraint groups are to be mapped to target resource locationsthat are less than or more than a defined level of proximity), with eachspecified constraint group having a distinct reference.

In other embodiments, a group of one or more resource usage constraintsmay be specified in other and/or additional ways. For example, one ormore groups may be predefined by the Client Resource Constraint ManagerService and made available for use by clients. In addition, a group maybe defined by a client and shared with one or more other clients, suchthat the one or more other clients may use the defined group to controlresource provider services in the same constrained manner as the client(e.g. such that computing-related resources used by resource providerservices on behalf of the one or more other clients are located at thesame one or more mapped target resource locations for the constraintgroup, so that use of all of the computing-related resources for thevarious clients occur near each other). In other embodiments, a clientmay have no knowledge of a Resource Constraint Manager Service, but mayinstead interact with a resource provider service that interacts withthe Resource Constraint Manager Service on behalf of the client. Forexample, the resource provider service may offer capabilities that arebased on use of one or more other resource provider services, and suchuse of the other resource provider services may be constrained in thevarious ways discussed elsewhere based on constraints specified by theclient to the resource provider service. In such a situation, theresource provider service may interact with the Client ResourceConstraint Manager Service on the client's behalf to specify the groupof one or more resource usage constraints.

At some time after the interactions 105 a 1 and 105 a 2, client Z makesa request 105 a 3 to resource provider service A to obtain capabilitiesthat will involve service A using one or more computing-relatedresources on behalf of client Z. As part of the request, client Zprovides the reference associated with the specified group of one ormore constraints, so that the resource usage by service A is performedin accordance with client Z's specified group of one or moreconstraints. Resource provider service A then makes a request 120 a 1 tothe Client Resource Constraint Manager Service to retrieve constraintgroup information related to the specified constraint group, such as bypassing the received reference for the constraint group. In interaction120 a 2, the Client Resource Constraint Manager Service then providesthe requested constraint group information to resource provider serviceA. In this example, the constraint group is not mapped to any particulartarget resource location, although the constraints of the group maylimit which geographical locations may be used (e.g., if a constraint ofthe group specifies that a geographical area of the United States beused, the location N 130 c in Paris, France will not be available to beused).

After the resource provider service A receives the constraint groupinformation associated with the reference provided by the client Z, theresource provider service A identifies one or more target geographicallocations that satisfy the constraint group and that are available toservice A for use of the type of computing-related resources needed tosatisfy Client Z's previously received request. As an example, theconstraint group information may indicate that the client Z desiresresource provider services using this particular group of constraints touse computing-related resources geographically located in the UnitedStates. In this example, the resource provider service A has access toat least two resource usage locations in the United States for use ofone or more types of computing-related resources on behalf of clients,those being resource usage location 1 in Seattle, Wash., and resourceusage location 2 in Philadelphia, Pa. Thus, resource provider service Amay satisfy the constraint group information by using computing-relatedresources on behalf of the client Z in either of these locations (or inboth locations if there are no constraints related to proximity of thevarious computing-related resources being used). In this example,resource provider service A selects resource usage location 1 inSeattle, Wash., and initiates interaction 120 a 3 with the ClientResource Constraint Manager Service to request that the constraint groupbe mapped to that target resource location, which the Client ResourceConstraint Manager Service accepts (e.g., based on a first-come basisthat allows any of the resource provider services to specify the mappedtarget geographical location for the constraint group if there is notany other currently mapped location). In interaction 120 a 4, theresource provider service A then interacts with computing-relatedresources located at resource usage location 1 as part of providingfunctionality to client Z, such as to perform initialization related tothe resource usage (e.g., if the resource is storage, to allocate aparticular block of storage that is available to Client Z) and/or tobegin using one or more computing-related resources for Client Z.

In this example embodiment, the resource provider service A initiatesthe mapping of Client Z's constraint group to target resourcelocation 1. The Client Resource Constraint Manager Service then storesthe provided mapping information and associates it with the referencedconstraint group information, such that it may be provided to otherresource provider services requesting constraint group informationassociated with the constraint group. In such cases, other resourceprovider services may later use other computing-related resources onbehalf of the client at the mapped target locations.

The use of computing-related resources by service A on Client's Zbehalf, and Client Z's access to related functionality provided byservice A, may be performed in various ways in various embodiments. Forexample, resource provider service A may provide functionality thatincludes persistent data storage, such that when client Z interacts withservice A to store data and/or to request previously stored data,service A will use persistent data storage devices located in resourceusage location 1. Client Z's interactions to receive such functionalitymay be performed in various ways in various embodiments. For example,service A may act as an intermediary between Client Z and the one ormore remote computing-related resources for each interaction, or inother embodiments, the client may be directed to interact directly withthe remote computing-related resources (e.g., if the resource providerservices provides the client with a URI to the resource). Alternatively,in some embodiments, service A may provide instances of the service ateach of multiple resource usage locations (e.g., with a front-end loadbalancer or other mechanism to handle initial client requests), andClient Z may be directed to interact directly with the service Ainstance at resource usage location 1 (e.g., service A may provideClient Z with a URI to that instance of service A for futureinteractions).

Thus, by using the described techniques, clients may control use ofcomputing-related resources by resource provider services on behalf ofthe clients, such as by specifying a group of one or more resource usageconstraints. Although FIG. 2A discusses client Z interacting withresource provider service A, it will be appreciated that client Z may inaddition or instead interact with other resource provider services(e.g., resource provider service B 120 b and/or resource providerservice L 120 c) to similarly control use of computing-related resourcesby these other resource provider services on behalf of client Z, andthat other clients may similarly interact with one or more of theresource provider services 120.

FIG. 2B continues the example of FIG. 2A at a subsequent time. In thisexample, resource provider service A has determined to attempt to switchthe mapped target geographical location for Client Z's constraint groupto a different geographical location that satisfies the constraint group(e.g., to another data center in a different location, such as due tothe initial data center becoming over-utilized or a new data centerbecoming available), which in this example is resource usage location 2130 b in Philadelphia, Pa. After making this determination, resourceprovider service A initiates an interaction 120 a 5 with the ClientResource Constraint Manager Service to attempt to update the mapping forclient Z's constraint group. In some embodiments, the Client ResourceConstraint Manager Service may inform a resource provider service thatan update cannot be performed (e.g., if the mapping conflicts with amapping previously provided by another resource provider service, orsome other restrictions or circumstances that prevent an update fromoccurring, such as a failed negotiation), and in such cases, theresource provider service will not be able make the switch and will haveto continue to use resources on behalf of the client in the previouslymapped target geographical location(s). If the update succeeds, theClient Resource Constraint Manager Service stores the updated mappinginformation for the constraint group, such that it may be provided toother resource provider services requesting to use informationassociated with the constraint group.

In this example, since no other resource provider services are using theconstraint group, the mapping update is successful. Accordingly, inresponse to subsequent interactions 105 a 4 by Client Z with service Arelated to use of computing-related resources, resource provider serviceA performs further corresponding interactions 120 a 6 so as to usecomputing-related resources on Client Z's behalf at resource usagelocation 2. In some situations, a switch between mapped targetgeographical locations may only impact future interactions on behalf ofthe client with computing-related resources located in the new location.However, in other situations, such as involving ongoing use of one moreresources, the switch may involve the transfer of data associated withthe client (e.g., data provided by the client in past interactions witha resource provider service) between locations so as to migrate to thenewly mapped target geographical location (e.g., migrating persistentdata stored on behalf of a client by copying the data to resourceslocated in the new target locations and deleting it from resourceslocated in the prior mapped target locations). In the illustratedembodiment, optional interaction 130 a 1 indicates such migration ofdata associated with client Z from computing-related resources inresource usage location 1 to computing-related resources in resourceusage location 2.

In some embodiments, after a resource provider service updates mappedtarget resource geographical location information associated with aparticular group of constraints, the Client Resource Constraint ManagerService may notify other resource provider services that use theparticular constraint group, such as to notify other resource providerservices to perform any necessary updates, initialization, and/or datamigration, etc. associated with the switch. Alternatively, in otherembodiments, resource provider services may periodically check with theClient Resource Constraint Manager Service to determine if an update hasoccurred.

FIG. 2C continues the examples of FIGS. 2A and 2B at a time after thepreviously described interactions of FIG. 2B. In the illustratedembodiment of FIG. 2C, Client Z is interacting with resource providerservice B 120 b, which has access to one or more types ofcomputing-related resources located at resource usage location 2 130 b(and possibly at one or more other resource usage locations). Inparticular, Client Z initiates an interaction 105 a 5 with service B,such as a request for capabilities from service B that will involveservice B using computing-related resources on behalf of client Z. Aspart of the request, client Z provides to service B the same referenceassociated with the previously specified group of one or moreconstraints of client Z.

In interaction 120 b 1, service B then requests constraint groupinformation associated with the referenced constraint group from theClient Resource Constraint Manager Service, and interaction 120 b 2depicts service B receiving the requested constraint group information,including the mapping of the constraint group to target geographicallocation resource usage location 1. After receiving the constraint groupinformation, service B then determines whether it can provide therequested functionality to client Z in accordance with the specifiedconstraint group, including performing any relevant computing-relatedresource use for Client Z at the current mapped resource usage location2. In this example, service B is able to satisfy the constraint group.Accordingly, in interaction 120 b 4, service B interacts with one ormore computing-related resources located at resource usage location 2 aspart of responding to Client Z's request. As an illustrative example,service B may provide functionality that includes program executionservices, so as to execute one or more software applications (e.g.,virtual machine computing instances) on behalf of client Z on one ormore computing systems located at resource usage location 2 inPhiladelphia, Pa. The execution of such programs may further use some ofthe data stored by Client Z based on prior interactions with service A(e.g., based on the executing program dynamically reading or otherwiseretrieving that information), and thus the execution of the programs maybenefit from occurring near to the location where that data is stored(e.g., to minimize latency, to minimize the inability to retrieve datadue to temporary transmission problems over network 100 between resourceusage locations, etc.). Thus, in the example embodiment, client Z hasspecified resource usage constraints that control use ofcomputing-related resources by both resource provider services A and B,such that resource provider services A and B both concurrently usecomputing-related resources located in resource usage location 2 onbehalf of client Z.

FIG. 2D continues the examples of FIGS. 2A-2C at a time after thepreviously described interactions of FIG. 2B. In particular, in theillustrated embodiment, Client Y initiates an interaction 105 b 1 withthe Client Resource Constraint Manager Service 110 to specify a group ofone or more resource usage constraints for Client Y, at least some ofwhich may be different than the one or more resource usage constraintspreviously specified by Client Z. For example, Client Y may specify oneor more constraints that indicate a geographical location of Seattle,Wash. in which computing-related resources are to be used on Client Y'sbehalf. A reference associated with the specified constraint group isreturned to Client Y in interaction 105 b 2, which is a distinctreference from that provided to Client Z for the constraint groupspecified by Client Z. In interaction 105 b 3, Client Y then sends arequest to resource provider service A for one or more types offunctionality that involve service A using one or more computing-relatedresources on behalf of Client Y, and provides the reference for thespecified constraint group that will control the use of those resources.Resource provider service A then requests and receives the constraintgroup information associated with Client Y's group of constraints, asshown in interactions 120 a 7 and 120 a 8.

After receiving the constraint group information, resource providerservice A then determines from the information that Client Y hasspecified the geographical location of Seattle, Wash., and in thisexample is able to access and use computing-related resources located ina data center represented by resource usage location 1 in Seattle, Wash.Accordingly, in interaction 120 a 9, resource provider service A sends arequest to the Client Resource Constraint Manager Service to mapresource usage location 1 to Client Y's constraint group, and receivesindication of approval of that mapped location. In other embodiments,resource provider service A may further have access to computing-relatedresources in multiple data centers at various locales in Seattle, Wash.(e.g. Seattle resource usage location 1, Seattle resource usage location2, etc.), and if so may select a particular one or more of the variousdata centers to use in accordance with Client Y's constraint group, andprovide information to the Client Resource Constraint Manager Serviceregarding those selected data centers. In such embodiments, the ClientResource Constraint Manager Service may map the particular data centersto Client Y's constraint group, or instead map the constraint group tothe geographical location of Seattle, Wash. (and further track whichdata centers are used by service B, such as to allow other resourceprovider services to satisfy proximity-related constraints for theconstraint group that involve the use of other resources within the samedata centers) or to other levels or types of geographical locations(e.g., to multiple related data centers that are located within aspecified geographical area and/or that are connected via one or morehigh-speed data connections). In interaction 120 a 10, resource providerservice A then initiates use of one or more computing-related resourcesat resource usage location 1 on behalf of Client Y, such as whileconcurrently using one or more computing-related resources at resourceusage location 2 for Client Z as discussed with respect to FIG. 2B.Thus, in the illustrated embodiment of FIGS. 2A-2D, resource providerservice A provides functionality to both Clients Z and Y, and usescomputing-related resources mapped to different target geographicallocations for the clients based on constraints specified by the clients.

As previously noted, clients may specify and use a variety of types ofcomputing-related resource usage constraints in various embodiments, andsuch constraints may take a variety of forms. For example, a client mayspecify constraints related to a particular geographical location, suchas by indicating a location of one or more computing systems or othercomputing-related resources (e.g., a data center, a group of multiplerelated data centers, a particular physical computing system, aparticular rack of multiple computing systems, a group of computingsystems connected by one or more particular network switches or othernetworking devices, etc.), by specifying a particular geographical area(e.g., North America, Europe, Asia, the Pacific Northwest, the PacificRim, etc.), by specifying a geopolitical entity (e.g., a state, anation, a community of nations such as the European Union, etc.), byspecifying a geographical area within a geopolitical entity (e.g., theWest Coast of the United States), etc. In other embodiments,location-related constraints may be specified in other manners, such ason the basis of regulatory considerations (e.g., regulations of ageopolitical entity, such as taxation, privacy rights, etc.), such thatthe constraint corresponds to one or more geographical locationsconsistent with the client-specified regulatory considerations.

Another example of a type of constraint related to geographicallocations that may be used in some embodiments are constraints relatedto operational characteristics of use of computing-related resources byresource provider services (e.g., latency, bandwidth, throughput, etc.),such that network services operating on behalf of a client may utilizecomputing-related resources in a geographical location consistent withclient-specified operational characteristics. As one illustrativeexample, consider a client that provides capabilities to customers whoare located in a particular geographical area. The provided capabilitiesof the client may use resource provider services that usecomputing-related resources on behalf of the client. In this situation,for example, the client may specify constraints to minimize latencyassociated with use of the resource provider services related to thecustomers, such as when providing information to customers from storageprovided by a resource provider service. Accordingly, such constraintsmay cause the resource provider services to use computing-relatedresources that are geographically located near the particulargeographical area of the customers, such as to minimize the distancebetween the computing-related resources and the customers.

Individual constraints and groups of constraints may have various formsin various embodiments. For example, in some embodiments, a group ofconstraints may be specified as an XML document, with each constraintbeing a tagged portion of the document. In other embodiments, eachconstraint may be specified in other forms, such as a rule, an if-thenstatement, executable code that provides output indicating theconstraint content (e.g., based on obtaining one or more types of input,such as current conditions) and/or indicating whether particular inputinformation (e.g., a geographical location) satisfies the constraint,etc. The types of constraints that may be specified may further beextendible in at least some embodiments, such as to allow a resourceprovider service to specify new types of constraints for use by itselfand/or by any resource provider service. In addition, in at least someembodiments, some individual constraints may further be specified by aclient to apply only in certain situations, such as only for particulartypes of resources, only for particular resource provider services ortypes of resource provider services, only at certain times or whencurrent conditions satisfy other indicated criteria, etc.

In addition, access to a specified group of constraints may becontrolled in various ways in various embodiments. For example, in someembodiments a constraint group may be publicly available to any resourceprovider services and/or clients that request information about theconstraint group, while in other embodiments a particular constraintgroup may have various access restrictions that are specified by theClient Resource Constraint Manager Service and/or by the client thatspecified the constraint group. As one example, a constraint group maynot be accessible other than by parties that demonstrate authorizationto access the constraint group, such as the reference generated for theconstraint group and/or other access authorization information (e.g., apassword, an indication of access rights delegated by the client thatspecified the constraint group, etc.). In addition, in some embodiments,a constraint group may be private, such that access is provided only tothe client that specified the constraint group and to others authorizedby the client (e.g., to resource provider services that the clientinstructs to use the constraint group).

In addition, an embodiment of the Client Resource Constraint ManagerService may have various forms and be implemented in various ways. Forexample, in some embodiments the Client Resource Constraint ManagerService may be a remote network service that various clients andresource provider services interact with over a network (e.g., clientsand resource provider services that are unaffiliated with the ClientResource Constraint Manager Service other than based on suchinteractions, such as to be provided by unrelated entities), and may beimplemented on a single physical computing system or instead in adistributed manner on multiple physical computing systems in differentgeographical locations. In other embodiments, the Client ResourceConstraint Manager Service may be integrated together with one or moreclient applications (e.g., such as to manage constraints for only thatclient application) and/or with resource provider services (e.g., suchas to manage constraints that are used only by those resource providerservices). In addition, the Client Resource Constraint Manager Servicemay facilitate various types of interactions by clients and resourceprovider services, including programmatic interactions based on an APIprovided by the Client Resource Constraint Manager Service and/orinteractive interactions based on a graphical user interface provided tousers (e.g., via one or more Web pages, via a client-side application ofthe Client Resource Constraint Manager Service that executes on acomputing device of a user, etc.).

In addition, in at least embodiments, various relationships may bespecified between multiple constraint groups. For example, in someembodiments, constraints may be specified between multiple constraintgroups, such as to indicate that two constraint groups are to be mappedto target resource locations that have a specified degree or type ofproximity (e.g., to be within an indicated distance, to be farther thanan indicated distance, to be sufficiently non-proximate to provide anindicated level of fault tolerance, to be sufficiently proximate toprovide an indicated level of bandwidth or to be less than an definedlevel of latency, etc.). In addition, in some embodiments a hierarchy ofconstraint groups may be specified, such that one constraint group isspecified to include all the constraints of one or more other constraintgroups, and optionally one or more additional constraints. Furthermore,in some embodiments, constraint groups may be organized based ongeographical locations and/or areas to which the constraint groups aremapped and/or are limited to.

FIG. 3 is a block diagram illustrating an example computing systemsuitable for performing techniques for facilitating client control overuse of computing-related resources on the client's behalf. Inparticular, FIG. 3 illustrates a server computing system 300 suitablefor executing an embodiment of a Client Resource Constraint ManagerService, as well as various client computing systems 350, resourceprovider service computing systems 360, and other computing systems 380.In the illustrated embodiment, the server computing system 300 hascomponents that include a CPU 305, various I/O components 310, storage320, and memory 330. The I/O components include a display 311, a networkconnection 312, a computer-readable media drive 313, and other I/Odevices 315 (e.g., a mouse, keyboard, speakers, etc.).

In this illustrated embodiment, a software Client Resource ConstraintManager system 340 is executing in memory 330 to provide a ClientResource Constraint Manager Service, and it interacts with the clientcomputing systems 350 and 360 over a network 390 using the networkconnection 312 (e.g., via the Internet and/or the World Wide Web,cellular network, etc.). In particular, an end-user of a clientcomputing system 350 may interact with the system 340 in order toprovide information about one or more groups of resource usageconstraints for the client, such as via a client application 359executing in memory 357 of the client computing system 350, as well asto perform other related interactions. The Client Resource ConstraintManager system stores the various client-specified constraintinformation in a database (“DB”) data structure 322 on storage 320, andmay further associate one or more references with each constraint group.In addition, as discussed in greater detail elsewhere, each group of oneor more constraints may be mapped to one or more target geographicallocations, such as based on decisions made by resource provider servicesas part of using computing-related resources of behalf of clients inaccordance with a group of constraints. Information about the targetgeographical locations to which constraints groups are mapped is storedin the illustrated embodiment in a database 324 on storage 320, althoughin other embodiments the information about constraints and about mappedtarget geographical locations may be stored in other manners, such as ina single database. In addition, a variety of other types of informationmay be stored and used by the Client Resource Constraint Manager systemin some embodiments, such as information about clients (e.g., clientlogin information, access rights and information regarding others whomay access and/or use a client's constraint group in one or more ways,etc.), and information about resource provider services (e.g.,information about possible geographical locations at which the resourceprovider service has access to use resources, information aboutparticular resources of particular types that the resource providerservice has access to use, etc.).

After a particular end-user client has specified a group of one or moreresource usage constraints, information about those constraints may thenbe provided by the system 340 to one or more resource provider servicecomputing systems 360 that provide functionality to the client. Inparticular, in the illustrated embodiment, each of the resource providerservice computing systems includes a system 369 executing in memory 367of the computing system 360 that provides a particular resource providerservice to clients (e.g., to client applications 359 of client computingsystems 350 on behalf of the end-user clients for those computingsystems). Each of the resource provider services provided by a system369 may use one or more computing-related resources of one or more typeson behalf of clients when providing functionality to those clients, suchas one or more computing-related resources from one or more of thecomputing systems 360 and/or from one or more of the other computingsystems 380. For example, computing-related resources that may be usedin at least some embodiments include access to one or more CPUs 381and/or CPUs 361, a portion of one or more memories 387 and/or memories367, a portion of one or more storages 384 and/or storages 364, accessto one or more I/O components 382 and/or I/O components 362, etc. Aftera resource provider service obtains information from the system 340regarding the constraints for a client (e.g., based on a reference to aclient's constraint group that the client provides to the resourceprovider service, and that the resource provider service provides to thesystem 340), the resource provider service determines where and how touse one or more resources on the client's behalf in accordance withthose constraints, including in accordance with any target geographicallocations to which a constraint group is mapped. The resource providerservice may further provide various information to the system 340regarding use of computing-related resources on clients' behalf, such asa particular geographical location at which the resource providerservice has selected to use such resources (e.g., from multiple possiblegeographical locations that all satisfy the constraints of the client).

In addition, one or more systems 344 may also optionally be executing inmemory 330 in some embodiments to each provide one or more otherresource provider services, such as if the same entity that provides thesystem 340 also provides the one or more systems 344. In otherembodiments, the system 340 may be unaffiliated with some or all of theresource provider services that obtain constraint information from thesystem 340.

Those skilled in the art will appreciate that the computing systems 300,350, 360 and 380 are merely illustrative and are not intended to limitthe scope of the embodiments of the present disclosure. For example, thesystem 340 may instead be executed by multiple interacting computingsystems or devices, and computing system 300 may be connected to otherdevices that are not illustrated, including through one or more networkssuch as the Internet, via the World Wide Web (“Web”), or otherelectronic communications network (e.g., cellular based network, publicswitched telephone network). More generally, a “client” or “server”computing system or computing device may comprise any combination ofhardware or software that can interact in the indicated manners,including (without limitation) desktop or other computers, networkdevices, PDAs, cellphones, wireless phones, pagers, electronicorganizers, Internet appliances, television-based systems (e.g., usingset-top boxes and/or personal/digital video recorders), game consoles,media players and various other consumer products that includeappropriate inter-communication capabilities. In addition, thefunctionality provided by the system 340 may in some embodiments bedistributed in various components. Similarly, in some embodiments, someof the functionality of the system 340 may not be provided, and/or otheradditional functionality may be available.

Those skilled in the art will also appreciate that, while various itemsare discussed or illustrated as being stored in memory or on storagewhile being used, these items or portions of them may be transferredbetween memory and other storage devices for purposes of memorymanagement and data integrity. Alternatively, in other embodiments someor all of the software systems or components of those systems mayexecute in memory on another device and communicate with the illustratedcomputing systems via inter-computer communication. Furthermore, in someembodiments, some or all of the systems and/or components may beimplemented or provided in other manners, such as at least partially infirmware and/or hardware, including, but not limited to, one or moreapplication-specific integrated circuits (ASICs), standard integratedcircuits, controllers (e.g., by executing appropriate instructions, andincluding microcontrollers and/or embedded controllers),field-programmable gate arrays (FPGAs), complex programmable logicdevices (CPLDs), etc. Some or all of the systems, components and/or datastructures may also be stored (e.g., as executable or othermachine-readable software instructions or structured data) on acomputer-readable medium, such as a hard disk, a memory, a network, or aportable media article to be read by an appropriate drive or via anappropriate connection. The systems, components and data structures mayalso be transmitted via generated data signals (e.g., as part of acarrier wave or other analog or digital propagated signal) on a varietyof computer-readable transmission mediums, including wireless-based andwired/cable-based mediums, and may take a variety of forms (e.g., aspart of a single or multiplexed analog signal, or as multiple discretedigital packets or frames). Such computer program products may also takeother forms in other embodiments. Accordingly, embodiments of thepresent disclosure may be practiced with other computer systemconfigurations.

FIG. 4 is a flow diagram of an example embodiment of a Client ResourceConstraint Manager routine 400. The routine may be provided by, forexample, execution of an embodiment of the Client Resource ConstraintManager Service 110 of FIG. 1 and/or of the Client Resource ConstraintManager system 340 of FIG. 3, such as to manage resource usageconstraints specified for clients in order to control use ofcomputing-related resources by other services on behalf of the clients.In this illustrated embodiment, constraints are specified by clients forthe clients, but in other embodiments the constraints may be specifiedin other manners. For example, in some embodiments, constraints may bespecified by or for entities other than clients, such as by or forresource provider services. In addition, in other embodiments,constraints may be specified for a client by someone other than theclient, such as automatically by the Client Resource Constraint ManagerService and/or by resource provider services. In addition, while in someembodiments the specified constraints control use of computing-relatedresources by resource provider services, in other embodiments theconstraints may be used in other manners, including to control sometypes of activities that are not related to use of computing-relatedresources, including at least some types of activities that areperformed by the Client Resource Constraint Manager Service.

The illustrated embodiment of the routine 400 begins at block 405, wherean indication is received of a request related to constraints and/or ofinformation related to constraints. The routine continues to block 410to determine whether a request was received from a client to define agroup of one or more client resource usage constraints for the client.If so, the routine continues to block 412 to obtain constraintinformation from the client, such as constraint information specified inthe request received in block 405, and/or information received in block412 based on an interaction with the client (e.g., an interactiveinteraction with a particular end-user client). The routine thencontinues to block 414 to create a constraint group for the client basedon the obtained constraint information. The creation of a constraintgroup may include, for example, generating one or more references forthe constraint group, so as to allow the client and/or resource providerservices to later reference the constraint group and obtain informationabout the constraints of the group. Such references may have variousforms in various embodiments, such as a unique identifier, acomputer-readable link or other network-accessible address, etc. Inother embodiments, one or more references for a constraint group may bedetermined in other manners, such as by being specified by the client.

After block 414, the routine continues to block 416 to optionallyidentify one or more target geographical resource locations that satisfythe constraints of the group, and if so to map those one or moreidentified target locations to the constraint group. For example, if theroutine 400 has access to information about the resource providerservices with which the constraint group may be used, and about possibletarget resource locations at which each of those resource providerservices are able to use resources, the routine may in some embodimentsautomatically determine one or more target resource locations that allof the resource provider services are able to use, and select thosetarget resource location(s) to be mapped to the constraint group suchthat each of the resource provider services will later use resources inaccordance with the constraint group at one or more of those mappedtarget resource locations. Alternatively, in other embodiments, the oneor more target resource locations to which a constraint group will bemapped may later be specified by one or more resource provider services,such as in a cooperative manner amongst multiple resource providerservices (e.g., based on an automated negotiation) or instead undercontrol of a single resource provider service (e.g., the first resourceprovider service to use the constraint group; a primary resourceprovider service that has authority to make the mapping determination,such as due to having the most constrained set of possible resourcelocations and/or having a highest associated priority; etc.). In otherembodiments, at least some constraint groups may not have mapped targetlocations, such that each resource provider service that uses resourcesin accordance with the constraint group will independently select atarget resource location at which to use resources, as long as theselected location satisfies the constraints of the constraint group.After block 416, the routine then continues to block 420 to store theinformation about the constraint group and any mapped target resourcelocation information. In block 422, the routine then indicates thesuccessful creation of the constraint group to the client, and in theillustrated embodiment provides to the client a reference that isassociated with the storage restraint group, for later use by the clientand/or other resource provider services in referencing the constraintgroup.

If it was instead determined in block 410 that the received request wasnot to define a client resource constraint group, the routine continuesinstead to block 430 to determine whether a request was received from aresource provider service to update information associated with a clientresource constraint group. In particular, in the illustrated embodiment,resource provider services send information to the Client ResourceConstraint Manager Service to provide information about their use ofcomputing-related resources in accordance with constraint groups, suchas to indicate geographical locations at which the resource providerservices are using such computing-related resources—for example, if theconstraint group is mapped to multiple target resource locations (e.g.,to a group of nearby data centers), a resource provider service mayindicate a particular one of the target resource locations at which theresource provider service is using resources, or may instead merelyindicate that the resource provider service is currently using one ormore resources at one or more of the mapped target resource locationswithout indicating a particular one. In addition, in at least someembodiments (e.g., embodiments in which the Client Resource ConstraintManager Service does not automatically determine mapped target resourcelocations for constraint groups), some or all resource provider servicesmay in at least some situations specify and update target resourcelocations to which constraint groups are mapped (e.g., if the constraintgroup is not currently mapped to any target resource location), asdiscussed in greater detail elsewhere. In the illustrated embodiment, ifit is determined in block 430 that a request was received from aresource provider service to update information associated with a clientresource constraint group, the routine continues to block 432 to receiveindicated target resource location information for an indicatedconstraint group (e.g., a constraint group indicated with an associatedreference for the constraint group, with an indication of the client towhich the constraint group is associated, etc.), such as based oninformation received with the request in block 405. Target resourcelocations may be indicated in various ways in various embodiments, suchas based on a defined addressing scheme (e.g., GPS coordinates, streetaddresses, etc.), from an enumerated list of predefined locations, etc.After block 432, the routine continues to block 434 to associate thereceived target resource location information with the constraint group,and in block 436 stores the target resource location information.

In addition, if the request from the resource provider service isfurther to map the indicated constraint group to the indicated targetresource location, and that mapping by that resource provided service isallowed, the information for the indicated constraint group will furtherbe updated in blocks 434 and 436 to reflect that mapping. While notillustrated here, in some embodiments, the routine may perform varioustypes of actions to determine whether the resource provider service isallowed to specify a mapped target resource location information for theindicated constraint group, such as based on access permissionspreviously defined for the constraint group, based on an indication fromthe resource provider service of other authorization from the client tospecify the mapped target resource location, based on whether any othertarget resource location information is currently mapped to theindicated constraint group (e.g., to allow resource provider services tospecify mapped target resource locations on a first-come basis for aconstraint group such that the mapping succeeds if there is not acurrent mapping), based on whether the indicated target resourcelocation is compatible with one or more other target resource locationsto which the indicated constraint group is already mapped (e.g., thatthe multiple target resource locations satisfy any proximity-relatedconstraints for the indicated constraint group), etc. If a resourceprovider service specifies that an indicated constraint group is to bemapped to an indicated resource location but that mapping is notallowed, however, the routine may in some embodiments respond to therequest with an indication of failure or an error. If so, the resourceprovider service may then optionally take one or more additional relatedactions, as discussed with respect to the resource provider serviceroutine illustrated in FIGS. 5A and 5B.

If it was instead determined in block 430 that the received request wasnot from a resource provider service to update information for a clientresource constraint group, the routine continues instead to block 450 todetermine whether a request was received for information about anindicated client resource constraint group, such as from a resourceprovider service. If so, the routine continues to block 452 to receivean indication of the constraint group of interest (e.g., based oninformation received with the request at block 405), such as a referenceassociated with a constraint group, an indication of the client to whomthe constraint group is associated, etc. In block 454, the routine thenretrieves stored information about the constraint group, including anyconstraints of the group and information about any target resourcelocation(s) to which the constraint group is mapped. In block 456, theroutine then provides at least some of the retrieved information aboutthe constraint group to the requester, such as to indicate informationabout the constraints and any mapped target resource location. While notillustrated here, in some embodiments the routine may further performadditional actions to restrict at least some information about theconstraint group for at least some requesters. For example, in someembodiments a requester may further need to illustrate permission from aclient or other access rights in order to obtain information about aparticular constraint group. In addition, in some embodiments, at leastsome resource provider services may be allowed to define constrainttypes that are specific to that resource provider service (or to a groupof multiple resource provider services), and if so, a particularconstraint group may include one or more such service-specificconstraints (e.g., as expressed by the client for use by that resourceprovider service, as expressed by the resource provider service based onprior interactions with the client and the constraint group, etc.)—insuch embodiments, if any such service-specific constraints are includedin a constraint group, those constraints may be provided only to thoseresource provider services to which the constraints correspond (and thusmay be removed from the constraint group information provided to otherresource provider services), although in other embodiments all suchconstraints may be provided to all resource provider services and suchservice-specific constraints may be ignored by other services to whichthose constraints do not correspond.

If it is instead determined in block 450 that the received request wasnot to obtain information about an indicated client resource constraintgroup, the routine continues instead to block 470 to perform one or moreother indicated operations as appropriate. For example, after defining aconstraint group, a client may determine to modify or update variousinformation about the constraint group, and if so that information maybe updated in block 470 based upon a corresponding client request. Inother embodiments, however, a client may not be allowed to update aconstraint group after it is created and/or after it is used by one ormore resource provider services (or while the constraint group is beingused by one or more resource provider services), such as to prevent aprior or ongoing use by a resource provider service of resources inaccordance with the constraint group to become invalid based on newchanges made by the client. In addition, as previously noted, in someembodiments multiple resource provider services may interact in order tonegotiate or otherwise determine one or more target resource locationsto which a particular constraint group is to be mapped, and if so theroutine may in at least some such embodiments facilitate suchnegotiation in block 470 by forwarding messages between the resourceprovider services and/or performing other operations to facilitate thenegotiation.

Similarly, as previously noted with respect to block 416, in at leastsome embodiments the routine 400 may further perform automatedactivities related to mapping at least some constraint groups toparticular target resource locations, such as to reflect one or moreresource provider services that may use the constraint group—in suchembodiments, the routine 400 may further at times (e.g., periodically)determine to assess whether to modify the target resource locations towhich particular constraint groups are currently mapped, such as toselect a new mapped target resource location for a constraint group soas to accommodate the various resource provider services that arecurrently using the constraint group (e.g., whether in a cooperativemanner with those resource provider services based on interactions withthem, or instead in a manner independent of those resource providerservices), and/or to otherwise reflect current conditions. If so, theroutine in block 470 may receive an indication (e.g., based onexpiration of a timer) to perform such an assessment and optionally tomodify target resource locations to which one or more constraint groupsare mapped, and if so perform those operations with respect to block470. In addition, the routine 400 may further notify any resourceprovider services that are currently using a constraint group of thechange in the mapped target resource location for the constraint group,such as by pushing information to those resource provider services aboutthe new mapped target resource locations. Various other types ofoperations may similarly be performed with respect to block 470 in atleast some embodiments.

After blocks 422, 436, 456, or 470, the routine continues to block 495to determine whether to continue. If so, the routine returns to block405, and if not continues to block 499 and ends.

FIGS. 5A and 5B are a flow diagram of an example embodiment of aResource Provider Service routine 500. The routine may be provided by,for example, execution of a resource provider service that usesresources on behalf of clients in accordance with specified constraintsof the clients, such as one of the services 120 of FIG. 1, one of theservices 369 of FIG. 3, and/or one of the services 344 of FIG. 3. In theillustrated embodiment, only a subset of the activities of each suchresource provider service is illustrated, in particular for a subset ofactivities related to interactions with an embodiment of a ClientResource Constraint Manager Service (e.g., as described with respect toroutine 400 of FIG. 4). It will be appreciated that each such resourceprovider service will further provide various service-specificcapabilities to clients and take various corresponding actions, whichare not illustrated here for the sake of brevity.

The illustrated embodiment of the routine begins at block 505, where anindication is received of a request from a client or of anothercommunication (e.g., from the Client Resource. Constraint ManagerService or from another resource provider service). The routinecontinues to block 510 to determine if the received request is a requestfrom a new client that involves use of one or more resources on behalfof the client to accommodate the request. If so, the routine continuesto block 510 to retrieve information from the Client Resource ConstraintManager Service about an indicated constraint group for the client, suchas based on a constraint group resource or other indication that isreceived from the client in the request received in block 505 and/orinteractively in block 515. As described with respect to blocks 452-456of FIG. 4, such retrieved constraint group information may includeinformation about the one or more specified constraints of the group,and any target resource location(s) to which the group is currentlymapped. Furthermore, in some embodiments in which other resourceprovider services are currently using resources in accordance with theconstraint group at one or more particular target resource locations,such information may further be provided to the routine in block 515.

After obtaining the information related to the constraint group, theroutine continues to block 520 to attempt to determine a target resourcelocation that is available to the resource provider service at which touse the indicated resources on behalf of the client, and that furthersatisfies the retrieved constraint group information, including anyexisting mappings of target resource locations for the constraint group.In block 525, the routine determines whether it can satisfy theconstraint group with such a service-specific target resource location,and if so continues to block 530 to contact the Client ResourceConstraint Manager Service to update information for the constraintgroup to indicate the service-specific target resource location that theservice will use. In this manner, other resource provider services thatlater obtain information about the constraint group may be able toperform their own service-specific determinations of target resourcelocations in a manner to satisfy any constraints related to proximity ofthe later services' resource usage with the resource usage by thecurrent service. The routine then continues to block 535 to initiate orotherwise perform use of or other interactions with one or morecomputing-related resources at the determined service-specific targetresource location on behalf of the client, such as part of complyingwith the received request from the new client. In block 540, the routineoptionally performs other tasks, such as to further perform otheractions related to complying with the request of the new client.

If it was instead determined in block 525 that the resource providerservice is not able to determine a service-specific target resourcelocation to use that satisfies the constraint group, the routinecontinues instead to block 545. For example, the resource providerservice may have one or more possible target resource locations to usethat would satisfy the constraints of the constraint group, but thosepossible target resource locations are not among the one or morecurrently mapped target resource locations for the constraint group.Alternatively, the constraint group may specify a geographical area inwhich the resource provider service does not have access to use anyresources that are needed to comply with the new client's request, andso is unable to comply with that request. In some such embodiments whenthe current resource provider service cannot comply with the clientrequest, the resource provider service may merely fail (e.g., respondingto the client request with an error or other indication of failure)—ifso, the client may subsequently choose to modify the constraints and/orinitiate a change in any mapped target resource locations for theconstraint group (e.g., by interacting with one or more other resourceprovider services that are currently using resources on the client'sbehalf in those mapped target resource locations), and then re-submitthe same request to the current resource provider service.

In the illustrated embodiment, however, the Client Resource ConstraintManager Service may provide functionality to facilitate a negotiationprocess between resource provider services to attempt to resolvesituations in which the current resource provider service has one ormore possible target resource locations that would satisfy theconstraints of the constraint group, if a currently mapped targetresource location for the constraint group was changed to include one ormore of those other possible target resource locations. Accordingly, inblock 545, the illustrated embodiment of the routine contacts the ClientResource Constraint Manager Service and attempts to obtain a resolutionof such a new mapped target resource location for the constraint group,such as by supplying information to the Client Resource ConstraintManager Service that indicates the one or more possible target resourcelocations that the current resource provider service could successfullyuse in accordance with the constraints of the group. As previouslynoted, the Client Resource Constraint Manager Service may in someembodiments facilitate such negotiations by forwarding the receivednegotiation request onto one or more other resource provider servicesthat currently use the constraint group, such as to allow those resourceprovider services to determine whether or not they are willing and ableto change the mapped target resource locations for that constraint groupto one of the possible target resource locations indicated by the clientresource provider service. In other embodiments, the Client ResourceConstraint Manager Service may instead respond to such a negotiationrequest by automatically determining whether or not to modify the mappedtarget resource locations for a constraint group (e.g., if otherresource provider servicers were previously using resources at thecurrently mapped target resource locations in accordance with theconstraint group, but are no longer doing so). In block 555, the routinereceives a response to the negotiation resolution initiated in block 545(e.g., after a period of time, such as while the routine 500 continuesto perform other operations on behalf of this and/or other clients in anasynchronous manner). If a new target resource location mapping for theconstraint group is successfully obtained, the routine continues fromblock 555 to block 535, and otherwise continues to block 560 to providean error to the client that the client request cannot be satisfied inaccordance with the current constraint group information. As previouslynoted, in other embodiments blocks 545 and 555 may not be performed,such as to continue directly from block 525 to block 560 if thedetermination in block 525 is unsuccessful.

If it was instead determined in block 510 that the received request wasnot a request from a new client related to resource usage, the routinecontinues to block 565 to determine whether to attempt to change amapped target resource location for a constraint group for which one ormore resources are being used for a client. For example, the routine mayidentify that the computing-related resources in a particularservice-specific target resource location are over-utilized orunder-utilized, and so may attempt to move resource usage for one ormore clients from or to those locations, respectively. The determinationto attempt to change a target resource location may arise in variousways in various embodiments, such as based on a periodic check (e.g., astriggered by expiration of a timer), by an alarm or other indicationthat is triggered based on an amount of use of computing-relatedresources at a particular resource location rising above or below athreshold, etc. If it is determined in block 565 to attempt to change atarget resource location for a constraint group, the routine continuesto block 567 to attempt to identify one or more new service-specifictarget resource locations that satisfy the constraints of a selectedconstraint group and that otherwise would be preferred by the currentresource provider service over the current mapped target resourcelocations for the selected constraint group. In block 568, if one ormore such new service-specific target resource locations are identified,the routine then contacts the Client Resource Constraint Manager Serviceand attempts to update the mapped target resource locations for theselected constraint group to the new identified service-specific targetresource location. As previously noted, in some embodiments a particularresource provider service may be allowed to update a mapped targetresource location for a constraint group in at least some situations(e.g., if the current resource provider service is the primary resourceprovider service for the constraint group, if the current resourceprovider service is the only or first resource provider service usingthe constraint group, etc.), while in other embodiments such an updateis allowed only if agreed to by the Client Resource Constraint ManagerService and/or by other resource provider services (e.g., other resourceprovider services that are currently using resources on the client'sbehalf in accordance with the constraint group). After block 568, theroutine then continues to 570 to determine whether the Client ResourceConstraint Manager Service indicates a successful update of the mappedtarget resource location for the selected constraint group. If so, theroutine continues in block 572 to initiate continuing and/or future useof resources on behalf of the client in accordance with the constraintgroup at the identified new service-specific target resource location(e.g., to move previously stored data for the client from the priormapped target resource location to the identified new service-specifictarget resource location). If it is instead determined in block 570 thatthe attempt to change the target resource location for the selectedconstraint group was not successful, or if no new service-specifictarget resource locations are identified in block 567, the routinecontinues instead to block 585, where an error is optionally reported(e.g., if the determination to attempt to change the mapped targetresource location was initiated in response to a request from a clientor other user, such as to update that client or user of the inability toupdate the mapped location).

If it was instead determined in block 565 that the request was not anattempt to change the mapped target resource location for a constraintgroup, the routine continues instead to block 580 to perform one or moreindicated operations as appropriate. For example, as previously noted,in at least some embodiments, a negotiation process between resourceprovider services and and/or with the Client Resource Constraint ManagerService may be performed, and if so such negotiation requests sent tothe current resource provider service may be handled in block 580 (in amanner similar to that of block 567, such as to identify whether anyservice-specific target resource locations are available to the currentservice that satisfy an indicated constraint group and that areacceptable to the other party that initiated the negotiation).Furthermore, as previously noted, each resource provider service mayperform various other service-specific operations (on behalf of clientsor otherwise), and such operations may be handled in block 580.

After blocks 540, 560, 572, 580, or 585, the routine continues to block595 to determine whether to continue. If so, the routine returns toblock 505, and if not continues to block 599 and ends.

Those skilled in the art will appreciate that in some embodiments thefunctionality provided by the routines discussed above may be providedin alternative ways, such as being split among more routines orconsolidated into fewer routines. Similarly, in some embodimentsillustrated routines may provide more or less functionality than isdescribed, such as when other illustrated routines instead lack orinclude such functionality respectively, or when the amount offunctionality that is provided is altered. In addition, while variousoperations may be illustrated as being performed in a particular manner(e.g., in serial or in parallel, synchronously or asynchronously, etc.)and/or in a particular order, those skilled in the art will appreciatethat in other embodiments the operations may be performed in otherorders and in other manners. Those skilled in the art will alsoappreciate that the data structures discussed above may be structured indifferent manners, such as by having a single data structure split intomultiple data structures or by having multiple data structuresconsolidated into a single data structure. Similarly, in someembodiments illustrated data structures may store more or lessinformation than is described, such as when other illustrated datastructures instead lack or include such information respectively, orwhen the amount or types of information that is stored is altered.

From the foregoing it will be appreciated that, although specificembodiments have been described herein for purposes of illustration,various modifications may be made without deviating from the spirit andscope of the invention. Accordingly, the invention is not limited exceptas by the appended claims and the elements recited therein. In addition,while certain aspects of the invention are presented below in certainclaim forms, the inventors contemplate the various aspects of theinvention in any available claim form. For example, while only someaspects of the invention may currently be recited as being embodied in acomputer-readable medium, other aspects may likewise be so embodied.

1. (canceled)
 2. A computer-implemented method for a constraint managernetwork service to manage constraints related to use ofcomputing-related resources by multiple other network services, themethod comprising: in response to information provided by a client,storing for the client a defined group of one or more constraints tocontrol use of computing-related resources on behalf of the client bythe multiple other network services; providing to the client a referencespecific to the defined group of one or more constraints for use by themultiple other network services in obtaining information about thedefined group of one or more constraints; after the client interactswith a first of the other network services and supplies the providedreference to the first network service, receiving a request from thefirst network service for information about constraints that correspondto the provided reference, and providing information about the definedgroup of one or more constraints to the first network service, so thatthe first network service uses one or more computing-related resourceson behalf of the client in a manner that satisfies the defined group ofone or more constraints; and after the client interacts with a second ofthe other network services and supplies the provided reference to thesecond network service, the second network service being distinct fromthe first network service, receiving a request from the second networkservice for information about constraints that correspond to theprovided reference, and providing information about the defined group ofone or more constraints to the second network service, so that thesecond network service uses one or more other computing-relatedresources in a manner that satisfies the defined group of one or moreconstraints, the one or more other computing-related resources beingdistinct from the one or more computing-related resources.
 3. The methodof claim 2 wherein the storing of the defined group of one or moreconstraints, the providing of the reference to the client, the providingof the information to the first network service, and the providing ofthe information to the second network service are performed undercontrol of the constraint manager network service, and wherein themethod further comprises, under control of the first network service:receiving a request from the client for functionality that includes useof the one or more computing-related resources on behalf of the client,the received request including the reference for the defined group ofone or more constraints that is supplied by the client; sending arequest to the constraint manager network service for information aboutconstraints that correspond to the supplied reference; receivinginformation that is provided from the constraint manager network serviceabout the defined group of one or more constraints; determining a mannerof using the one or more computing-related resources on behalf of theclient that satisfies the defined group of one or more constraints; andusing the one or more computing-related resources on behalf of theclient in the determined manner.
 4. The method of claim 3 wherein thereceived information that is provided from the constraint managernetwork service about the defined group of one or more constraintsincludes an indication of at least one of the one or more constraintsthat indicate a geographical area in which use of computing-relatedresources on behalf of the client is to occur, wherein the determiningof the manner of using the one or more computing-related resources onbehalf of the client includes selecting one of multiple geographicallocations within the geographical area that are available to the firstnetwork service for using the one or more computing-related resources onbehalf of the client, and wherein the using of the one or morecomputing-related resources on behalf of the client in the determinedmanner includes using the one or more computing-related resources at theselected location.
 5. The method of claim 4 further comprising: undercontrol of the first network service, sending information to theconstraint manager network service to indicate the selected onegeographical location; and under control of the constraint managernetwork service, after receiving the sent information that indicates theselected one geographical location but before providing the informationabout the defined group of one or more constraints to the second networkservice, mapping the defined group of one or more constraints to theselected one geographical location; and wherein the providing of theinformation about the defined group of one or more constraints to thesecond network service includes providing an indication of the selectedone geographical location, so that the second network service uses theone or more other computing-related resources at the selected onegeographical location.
 6. The method of claim 3 wherein the determiningof the manner of using the one or more computing-related resources onbehalf of the client includes identifying multiple availablecomputing-related resources that satisfy the defined group of one ormore constraints, and selecting a subset of the multiplecomputing-related resources to use on behalf of the client based atleast in part on current utilization of the subset of computing-relatedresources that differs from current utilization of other of the multiplecomputing-related resources and/or on costs of using the subset ofcomputing-related resources that differ from costs of using other of themultiple computing-related resources.
 7. The method of claim 2 whereinthe using by the first network service of the one or morecomputing-related resources on behalf of the client includes using theone or more computing-related resources at a first geographical locationthat is one of multiple geographical locations that satisfy the definedgroup of one or more constraints; wherein the method further comprises,after the first network service uses the one or more computing-relatedresources at the first geographical location, and before the providingof the information about the defined group of one or more constraints tothe second network service, receiving from the first network service anindication that the first network service has selected to performadditional use of at least one computing-related resource on behalf ofthe client at a selected distinct second geographical location that isone of the multiple geographical locations; and wherein the providing ofthe information about the defined group of one or more constraints tothe second network service includes providing an indication of theselected second geographical location, so that the using by the secondnetwork service of the one or more other computing-related resources isperformed on behalf of the client and at the second geographicallocation.
 8. The method of claim 2 wherein the using by the firstnetwork service of the one or more computing-related resources on behalfof the client includes identifying a first group of one or morecomputing systems that satisfy the defined group of one or moreconstraints, and interacting with the one or more computing systems touse computing-related resources provided by the computing systems of thefirst group; wherein the method further comprises, after the firstnetwork service uses the computing-related resources provided by thecomputing systems of the first group, and before the providing of theinformation about the defined group of one or more constraints to thesecond network service, receiving from the first network service anindication that the first network service has selected to performadditional use of at least one computing-related resource on behalf ofthe client by interacting with a selected distinct second group of oneor more computing systems; and wherein the providing of the informationabout the defined group of one or more constraints to the second networkservice includes providing an indication of the selected second group ofone or more computing systems, so that the using by the second networkservice of the one or more other computing-related resources isperformed on behalf of the client and by interacting with the one ormore computing systems of the second group.
 9. The method of claim 2further comprising: identifying one or more computing systems thatsatisfy the one or more constraints of the defined group; andassociating the identified computing systems with the defined group suchthat the use by the first network service of the one or morecomputing-related resources is performed based on interactions of thefirst network service with at least one of the identified computingsystems, and such that the use by the second network service of the oneor more other computing-related resources is performed based oninteractions of the second network service with at least one of theidentified computing systems.
 10. The method of claim 9 wherein theidentified one or more computing systems are selected based at least inpart on being located together at one or more identified geographicallocations, and wherein the associating of the identified computingsystems with the defined group includes mapping the defined group to theidentified one or more geographical locations, such that the use by thefirst network service of the one or more computing-related resources isperformed in at least one of the identified geographical locations, andsuch that the use by the second network service of the one or more othercomputing-related resources is performed in at least one of theidentified geographical locations.
 11. The method of claim 10 whereinthe identified one or more geographical locations to which the definedgroup is mapped are not identified to the client.
 12. The method ofclaim 9 wherein the identifying of the one or more computing systems isbased at least in part on information provided by at least one of thefirst and second network services, and wherein the identified one ormore computing systems include multiple computing systems that areavailable at one or more identified data centers.
 13. The method ofclaim 2 wherein the one or more constraints of the defined group includeat least one of an indication of a geographical location, an indicationof a geographical area with government-specified boundaries, anindication of a geographical area to which an indicated law applies, anindication of a geographical area to which an indicated tax applies, anindication of a degree of proximity to an indicated geographicallocation, an indication of a degree of proximity between multiplecomputing-related resources, an indication of a degree of proximity toan indicated entity, an indication of a degree of fault tolerance for atleast some of the computing-related resources used by the multiple othernetwork services on behalf of the client, and an indication of a pricerelated to use of a computing-related resource.
 14. The method of claim13 wherein the one or more constraints of the defined group include theindication of the degree of fault tolerance, and wherein the degree offault tolerance is based on at least one of a degree of proximitybetween two or more computing-related resources, a degree of proximityof one or more computing-related resources to an indicated geographicallocation, a type of computer hardware used to provide at least one ofthe computing-related resources, and a type of software used to provideat least one of the computing-related resources.
 15. The method of claim2 wherein at least one of the one or more constraints of the definedgroup indicate a level of one or more operational characteristics of useof one or more types of computing-related resources, and wherein themethod further comprises automatically determining one or morecomputing-related resources and/or one or more geographical locations ofcomputing-related resources that will provide the indicated level of theone or more operational characteristics.
 16. The method of claim 2wherein at least one of the one or more constraints of the defined groupis specific to the first network service, such that the use of the oneor more computing-related resources by the first network service onbehalf of the client is performed in accordance with the at least oneconstraint, and such that the use of the one or more othercomputing-related resources by the second network service on behalf ofthe client is not performed in accordance with the at least oneconstraint.
 17. The method of claim 2 wherein at least one of the one ormore constraints of the defined group is a conditional constraint thatis applicable only when current conditions satisfy indicated criteriafor the at least one constraint, such that the use of the one or morecomputing-related resources by the first network service on behalf ofthe client is performed in accordance with the at least one constraintbased on current conditions at a time of the use of the one or morecomputing-related resources, and such that the use of the one or moreother computing-related resources by the second network service onbehalf of the client is not performed in accordance with the at leastone constraint based on differing current conditions at a time of theuse of the one or more other computing-related resources. 18-22.(canceled)
 23. A computer-readable medium whose contents enable acomputing device to manage constraints related to use ofcomputing-related resources, by performing a method comprising: inresponse to information provided by a client, defining a group of one ormore constraints to control use of computing-related resources bynetwork services for the client; identifying one or more locations thatsatisfy the one or more constraints of the defined group; associatingthe identified one or more locations with the defined group, so that useof computing-related resources for the client occurs in at least one ofthe associated locations; and after the client interacts with a firstnetwork service regarding use of one or more computing-related resourcesby the first network service for the client, providing information tothe first network service about the defined group of one or moreconstraints and about the associated one or more locations, so that thefirst network service uses the one or more computing-related resourcesin at least one of the associated one or more locations and in a mannerthat satisfies the defined group of one or more constraints.
 24. Thecomputer-readable medium of claim 23 wherein the method is performedunder control of a constraint manager service provided by the computingdevice, wherein the one or more constraints of the defined group specifya geographical area that includes multiple geographical locations atwhich the first network service is able to use computing-relatedresources on behalf of the client, wherein the identifying of the one ormore locations includes identifying a subset of one or more of themultiple geographical locations of the specified geographical area,wherein the identifying of the one or more geographical locations isperformed based at least in part on information provided by the firstnetwork service to indicate a selection of the one or more geographicallocations from the multiple geographical locations, wherein theassociating of the identified one or more geographical locations withthe defined group includes mapping the defined group to the identifiedone or more geographical locations, and wherein the method furthercomprises providing information to multiple other network services aboutthe defined group of one or more constraints and about the associatedone or more geographical locations so that each of the other networkservices uses one or more computing-related resources on behalf of theclient in at least one of the associated one or more geographicallocations and in a manner that satisfies the defined group of one ormore constraints, the multiple other network services being distinctfrom the first network service and from the constraint manager service.25. The computer-readable medium of claim 23 wherein thecomputer-readable medium is at least one of a memory of a computingdevice and a data transmission medium that transmits a generated datasignal containing the contents, and wherein the contents areinstructions that when executed cause the computing device to performthe method.
 26. A computing system configured to manage constraintsrelated to use of computing-related resources, comprising: one or morememories; and a constraint manager system that is configured to manageresource usage constraints for clients by, for each of multiple clients:defining a group of one or more constraints to control use ofcomputing-related resources for the client by services external to theclient; associating with the defined group one or more locations thatare identified as satisfying the one or more constraints of the definedgroup; and for each of one or more services external to the client,providing information about the defined group of one or more constraintsto the service so that the service uses one or more computing-relatedresources for the client in a manner that satisfies the defined group ofone or more constraints, the provided information including theassociated one or more locations such that the use of the one or morecomputing-related resources by the service for the client occurs in atleast one of the associated locations. 27-29. (canceled)